this is a driver that is created and passed in a child class, here in parent class it is taken out from the controller and saved as a class object - wouldn't it be clearer to make it in a child class directly when driver is created?

The class is then in charge of making sure the driver and detector connect and parent/name relationship is correct rather than the API. It's much better to make sure the API does it as all classes will need to do this, otherwise we copy and paste this line x number times for number of implementations which is unnecessary.

you probably won't need to copy paste anything just add "self.driver" instead of making internal "driver" in a child class

The issue with this is that if we type anything as using the GenericElectronAnalyser for tests or plans or other devices i.e it doesn't care about if it Specs, Mbs, VGScienta etc. then it loses access to the driver because it lives now on the implementation and not on the base. We need it to be done here.

it looks like your use case for this is only relevant for tests, you probably could in analyser-related plan specify a parameter as GenericElectronAnalyser in a plan but you anyway want to operate using verbs so Movable, Readable or StandardDetector class (when it's there) would suffice? Isn't it the whole point of this change to get rid of generic analyser, am I missing smth?

or are you planning to call bps.move(analyser.driver) in a plan?

If the Bluesky change goes through with allowing devices have multiple configuration, then we can remove method create_region_detector_listand class GenericElectronAnalyserRegionDetector and GenericBaseElectronAnalyserDetector and just have only GenericElectronAnalyserDetector. We have to live with this complexity until this is done. This change is focusing on working with what what we got and letting it work with BlueAPI by removing file path dependency. The generic classes currently are only used in tests yes. They are a very convenient way to keep full typing for classes. Otherwise to have full typing I would have to do something like below

ElectronAnalyserDetector[AbastractRegion, AbstractDriverIO[AbstractRegion]]

and that isn't including the PsuMode, PassEnergy and LensMode types.

I think the reason they aren't used in the plans themselves is because they are invariant so has a couple of issues, but again this isn't related to this change.

Plans can still have full typing of the device and would need it to access child devices e.g

E.g

def my_plan(my_device: Movable):
     yield from mv(my_device.child_device1, 2) #invalid type checking
     yield from mv(my_device.child_device2, 5) #invalid type checking

If you give the correct type for the plan static type checking won't complain.

If you dislike the generics classes because they are only used in tests and not plans at the moment we can address this in a new issue/PR.

I rather dislike that inverse logic of having driver in base class via controller in child class that actually creates that driver -> which seems to be justified only for having GenericElectronAnalyser device having access to driver which is used only in tests and plan tests.

do you need this class here? it seems to be used only in tests

Yeah, this will be used in plan repo too.

which plan repo? sm-bluesky?

yes

https://github.com/search?q=repo%3ADiamondLightSource%2Fsm-bluesky%20GenericElectronAnalyserDetector&type=code

hmm again in tests...:)